A distributed transaction may include a set of processes or operations that may involve the use of more than one network host/resource. For example, a distributed transaction may call for database updates or operations using more than one database. A network host may provide for transaction resources utilized by a process, such as the database that requires updating and/or use. A transaction manager may receive a distributed transaction and prepare participating processes to execute on required network hosts. Thus, the transaction manager may prepare a coordinator network host/node that manages a set of participating network nodes each executing one or more processes of the distributed transaction.
Similar to other transactions, distributed transaction must maintain atomicity, consistency, isolation, and durability properties (ACID properties). Atomicity requires that changes made during processing a transaction are atomic, either all the changes to a database during an operation or update occur or they all do not occur. This prevents database updates from partially occurring, which would affect the reliability and consistency of databases. Additionally, durability requires that changes made as a result of processing a distributed transaction survive a system failure; that is results of a committed distributed transaction are durably recorded. In order to prevent violation of atomicity and durability, a transaction log is utilized to assist the transaction processing system with rollback for inconsistent states, to commit processes executed on a participating network host, and/or during recovery after a crash. However, performance for processing a distributed transaction is affected by the write speeds of a transaction log to a durable storage that can survive system (e.g., power) failure.